Great follow-up — the live tier-alias idea (so agents automatically ride the new flagship when MODEL_TIER_MAP is bumped) is a nice piece of engineering. Isolated from the PR #9 stack, this change is just +11 / −2 lines across 3 files, very clean. Opus 4.7 is the correct current flagship.

A few questions/asks before merge — nothing blocking, but worth clarifying:

❓ Motivation for resolving at dispatch

Right now both agent-factory.ts:27 and wizardConfigs.ts:167 already resolve tier → concrete model at agent creation time. So freshly created agents never store 'capable' in their YAML. Could you clarify which case this PR targets?

• (a) Backward-compat for older agent YAMLs stored before model-tiers.ts existed?
• (b) A new intentional capability — let users store tier aliases in YAML on purpose and have them re-resolve on every dispatch (so claude-opus-4-6 → claude-opus-4-7 migration is automatic)?
• (c) Accommodating hand-edited YAML?

If (b), it's worth a small companion change: the agent edit wizard could offer a "Use tier (capable/balanced/fast)" option alongside concrete model picks — otherwise the capability exists but has no user-facing way to opt in. A one-line README/CHANGELOG note explaining the semantic would also help.

🟡 Missing orchestrator test

The resolve logic touches core dispatch in orchestrator.ts but isn't covered by tests. Without one, a future refactor could silently drop the resolve step. Sketch (~10 lines) for test/unit/application/orchestrator.test.ts:

it('resolves tier alias in agent config before dispatch', async () => {
  const agent = makeAgent({ adapter: 'claude', config: { model: 'capable' } });
  // spy adapter.execute; run a tick; assert call.config.model === 'claude-opus-4-7'
});

There's also no assertion anywhere that claude.capable === 'claude-opus-4-7' — if model-tiers.test.ts exists it'll need an update; if not, this is a good opportunity to add one-line coverage.

🔵 Nits (optional)

• CLAUDE_MODELS now has two entries labeled "most capable" (4.7 and 4.6). Consider renaming the 4.6 hint to 'previous flagship' or 'legacy' so the picker has a single clear top choice.
• openrouter/anthropic/claude-opus-4.7 — have you verified this slug exists in OpenRouter's catalog today? A stale slug would 404 at dispatch from the opencode adapter.

🧵 Workflow — stacked on PR #9

This PR includes all three commits from PR #9. Since PR #9 has a blocker (Ctrl+S conflict with launchShopWizard at App.tsx:1808), how would you like to proceed?

• (A) Land PR Fix/textarea confirm and tui polish #9 first (after the Ctrl+S fix + optimistic-merge fallback), then rebase this one down to its own 3 commits — cleanest history.
• (B) Close PR Fix/textarea confirm and tui polish #9 and treat this one as the combined fix — requires me to re-review the TUI blocker here.

I'm fine with either. Let me know what fits your workflow.

Also heads-up: CI hasn't run on this PR yet because it inherits the same "first-time contributor" workflow gate as PR #9. I'll click Approve and run once the above is sorted so we see a green test check.

Thanks again — two solid PRs in a day is a rare signal 🙌